Remarks 



I. Response to Arguments Section 

The Final Rejection on page 16 includes a "Response to Arguments" section that 

states: 

Applicant's arguments filed 6/16/2011 have been fully considered 
but they are not persuasive. 

In the remarks on pgs. 11-14 and 18 of the amendment, the 
applicant contends that Kerr et al. in view of Willkie does not teach or 
suggest "decoding, by said network interface, a header of the first packet 
to determine a length of data to be stored in said destination entity, 
wherein said header conforms to a protocol above TCP" 

Examiner respectfully disagrees Kerr et al. teaches in particular 
transmission protocol type including TCP, the message flow is decoded 
using the information in the header to include the packet length. 

Applicants respectfully note that the Examiner's assertion as to what Kerr et al. 
teaches lacks elements of the claim portion quoted immediately prior. That is, 
Examiner's assertion does not indicate that Kerr et al. teaches that "said header conforms 
to a protocol above TCP." This is because Kerr et al. does not teach "decoding, by said 
network interface, a header. . . wherein said header conforms to a protocol above TCP." 
For at least this reason, the Final Rejection has not presented a prima facie case of 
obviousness for any claim, as discussed further below. 



II. 35 USC §103 - Kerr in view of Willkie 

The Office Action rejects claims 1-11, 17-22 and 24-27 under 35 USC § 103(a) as 
allegedly being unpatentable over U.S. Patent No. 6,243,667 to Kerr et al. ("Kerr") in 
view of U.S. Patent No. 6,682,851 to Willkie et al. ("Willkie"). 

A. Claim 1 

Regarding claim 1, the Office Action states: 

Regarding Claim 1 Kerr et al. discloses a method of identifying 
multiple packets in a communication flow between a source entity and a 
destination entity, comprising (see figure 2, message flow patterns): 

storing, in a network interface for the destination entity, a first flow 
identifier of a first packet received from a source entity for a destination 
entity, wherein said first flow identifier comprises an identifier of the 
source entity and an identifier of the destination entity, including source 
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and destination Transmission Control Protocol (TCP) port numbers (see 
col. 3, lines 57-67, flow identifying, identifying a flow for the packet, see 
col. 6, lines 29-41, the flow cache, stores the flow identifiers, including the 
source and the destination, see col. 1, lines 62-66, the collected 
information is reported to devices on the network( reads on network 
interface devices for the destination entity as broadly claimed), see also 
figure 1, section 540 reporting device, see col. 2 line 61- col. 3 line 2, a 
message flow 160 is defined by a network-layer address for a particular 
source device 120, a particular port number at the source device 120, a 
network-layer address for a particular destination device 130, a particular 
port number at the destination device 130, and a particular transmission 
protocol type. For example, the transmission protocol type may identify a 
known transmission protocol, such as TCP); 

decoding, by said network interface, a header of the first packet to 
determine a length of data to be stored in said destination entity, wherein 
said header conforms to a protocol above TCP( see col. 3, lines 25-34, a 
message flow may be identified responsive to other factors. These other 
factors may include one or more of the following: information in packet 
headers the packet length); 

storing, in the network interface said first packet in a packet 
memory for transfer toward the destination entity; storing, in said network 
interface a second flow identifier of a second packet( see col. 6, lines 32- 
42, flow cache( memory), stores the flow identifiers, see col. 3, lines 56- 
67, the router stores the packet for transfer to the destination); 

storing in said network interface said second packet in said packet 
memory; determining whether said first flow identifier matches said 
second flow identified see col. 3, lines 55-67, the router stores packets, 
and identifies the message flow using the flow identifier of the header); 

storing a first indicator in the destination entity if a first 
communication flow identified by said first flow identifier comprises said 
second packet;( see col. 7, lines 56-57, collecting and reporting 
information about messages flow, reporting reads on a indicator), see col. 
8, lines 35- 56, the routing device transmits the information packet about 
message flows( including the flow identified) to a destination device, see 
col. 4, lines 1-7, the routing device look up the flow cache to determine a 
flow, results are identified or new) and 

storing a second indicator in the destination entity if said first 
packet is the only packet stored in the packet memory that is part of said 
first communication flow( see col. 7, lines 56-57, collecting and reporting 
information about messages flow, reporting reads on a indicator), see col. 
8, lines 35-56, the routing device transmits the information packet about 
message flows( including when the flow identified includes only one 
packet) to a destination device, see col. 4, lines 1-7, the flow is identified 
as new if the first packet only packet part of the communication flow). 
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Kerr et al. fail to explicitly state storing a first indicator in the 
destination entity, and storing a second indicator in the destination entity 
as claimed. 

However Willkie et al. teaches storing a first indicator in the 
destination entity, and storing a second indicator in the destination entity 
(see col. 3, lines 45-65, Willkie et al. teaches a QMIP unit which receives 
and stores data from a set of modules, which comprises a memory which 
stores a received flow control indication from each module, the flow 
indicator indicates if transmission of data is to cease , the QMIP creates a 
frame which carries data information and flow control indication , the 
QMIP forward frame over the common data link). 

Therefore it would have been obvious to one with ordinary skill in 
the art at the time the invention was made to combine Kerr et al. invention 
with Willkie et al. invention because Willkie et al. transfers data between 
multiple entities over a serial link in a efficient manner( see Willkie et al. 
see col. 3, lines 38-41) 

Applicants respectfully disagree with this rejection. As noted above, applicants 
respectfully disagree that "Kerr et al. discloses ...decoding, by said network interface, a 
header of the first packet to determine a length of data to be stored in said destination 
entity, wherein said header conforms to a protocol above TCP( see col. 3, lines 25-34, a 
message flow may be identified responsive to other factors. These other factors may 
include one or more of the following: information in packet headers the packet length)." 
The citation of Kerr that the Final Rejection relies upon as allegedly disclosing this claim 
recitation reads: 

For example, in alternative embodiments, a message flow may be 
bi-directional instead of unidirectional, a message flow may be identified 
at a different protocol layer level than that of transport service access 
points, or a message flow may be identified responsive to other factors. 
These other factors may include one or more of the following: information 
in packet headers, packet length, time of packet transmission, or routing 
conditions on the network (such as relative network congestion or 
administrative policies with regard to routing and transmission). 

There is simply nothing in this quotation, or in the remainder of Kerr, that teaches 
"decoding, by said network interface, a header. . . wherein said header conforms to a 
protocol above TCP." There is no "protocol above TCP" mentioned. Packet length 
would have been easy for the router of Kerr to determine without decoding any header, 
by simply counting the bytes of the packet. Further, decoding a header of a layer above 
TCP would have been useless and a waste of processing resources for the router of Kerr, 
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which operated at layers below TCP. For at least these reasons, the Final Rejection has 
not presented a prima facie case of obviousness for claim 1. 

Applicants also respectfully disagree that "Kerr et al. discloses . . . storing a 
second indicator in the destination entity if said first packet is the only packet stored in 
the packet memory that is part of said first communication flow( see col. 7, lines 56-57, 
collecting and reporting information about messages flow, reporting reads on a indicator), 
see col. 8, lines 35-56, the routing device transmits the information packet about message 
flows( including when the flow identified includes only one packet) to a destination 
device, see col. 4, lines 1-7, the flow is identified as new if the first packet only packet 
part of the communication flow)." Although "col. 4, lines 1-7" of Kerr disclose 
determining whether "the identified message flow 160 is a 'new' message flow 160," 
Kerr does not teach that this determination is stored in the destination entity. Moreover, 
Kerr does not disclose that a second indicator is stored besides the first indicator, 
regardless of whether the packet is "new." For at least these additional reasons, the Final 
Rejection has not presented a prima facie case of obviousness for claim 1 . 

Applicants further respectfully disagree that "Willkie et al. teaches storing a first 
indicator in the destination entity, and storing a second indicator in the destination entity 
(see col. 3, lines 45-65, Willkie et al. teaches a QMIP unit which receives and stores data 
from a set of modules, which comprises a memory which stores a received flow control 
indication from each module, the flow indicator indicates if transmission of data is to 
cease , the QMIP creates a frame which carries data information and flow control 
indication , the QMIP forward frame over the common data link)." Willkie does not 
teach "storing a second indicator in the destination entity." Instead, col. 3, lines 53-57 of 
Willkie states: 

The QMIP unit also receives and stores a flow control indication 
from each module of a first set of modules. The flow control indication is 
indicative as to whether each module of the first set of modules is capable 
of receiving data. 

In other words, the only indicator for a module is "whether each module is 
capable of receiving data." For at least these additional reasons, the Final Rejection has 
not presented a prima facie case of obviousness for claim 1. 
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Moreover, applicants respectfully disagree that "it would have been obvious to 

one with ordinary skill in the art at the time the invention was made to combine Kerr et 

al. invention with Willkie et al. invention because Willkie et al. transfers data between 

multiple entities over a serial link in a efficient manner( see Willkie et al. see col. 3, lines 

38-41)." Instead, col. 3, lines 38-41 of Willkie state: 

Therefore, there is a need in the art for a means of transferring data 
between multiple entities over a single serial link. The invention fulfills 
this need in an efficient manner. 

In other words, Willkie stresses the importance of "a single serial link." In 
contrast, Kerr is directed to "a technique for network switching and data export 
responsive to message flow patterns." Col. 1, lines 43-45. A "single serial link" does not 
use "network switching" and "network switching" is not used for "a single serial link." 
Because Willkie and Kerr are directed to mutually exclusive purposes, a person of 
ordinary skill in the art would not have combined Kerr and Willkie as proposed by the 
Final Rejection. For at least this additional reason, the Final Rejection has not presented 
a prima facie case of obviousness for claim 1. 

Because of the multiple reasons why the Final Rejection has not presented a 
prima facie case of obviousness for claim 1, applicants respectfully assert that claim 1 
and all the claims that depend from claim 1 are nonobvious, and respectfully request that 
the rejection of those claims be withdrawn. 



B. Claims 3 and 22 

Regarding claims 3 and 22, the Office Action states: 

Regarding Claims 3 and 22 Kerr et al. discloses a method of 
identifying one or more packets in a communication flow between a 
source entity and a destination entity, comprising: 

receiving a first packet at a communication device that is a 
network interface for a host computer ( see col. 3, lines 55-56, receives a 
packet, see figure 1, section 140, routing device); 

identifying by said network interface a first communication flow 
comprising said first packet with a first flow identifier configured to 
identify both the source entity and the destination entity including source 
and destination Transmission Control Protocol (TCP) port numbers (see 
col. 3, lines 57-67, flow identifying, identifying a flow for the packet, see 
col. 6, lines 29-41, the flow cache, stores the flow identifiers, including the 
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source and the destination, see col. 2 line 61- col. 3 line 2, a message flow 
160 is defined by a network-layer address for a particular source device 
120, a particular port number at the source device 120, a network-layer 
address for a particular destination device 130, a particular port number at 
the destination device 130, and a particular transmission protocol type. For 
example, the transmission protocol type may identify a known 
transmission protocol, such as TCP); 

decoding, by said network interface, a header of the first packet to 
determine a length of data to be stored in said destination entity, wherein 
said header conforms to a protocol above TCP( see col. 3, lines 25-34, a 
message flow may be identified responsive to other factors. These other 
factors may include one or more of the following: information in packet 
headers the packet length); 

determining by said network interface whether said first 
communication flow also comprises a second packet received at said 
communication device after said first packet was received at said 
communication device( see col. 3, lines 49-67, the router determines the 
message flow of the received packets); and 

transferring said first packet to a host computer for processing in 
accordance with a communication protocol associated with said first 
packet (see col. 8, lines 35-59, the router build an information packet 
which is then sent to a destination device (host computer), in accordance 
to a communication protocol, for processing, see col. 2-3, lines 50-2, the 
router, processes in accordance to a transmission protocol type of the first 
packet). 

Kerr et al. fail to explicitly point out transferring said first packet 
to a host computer as claimed. 

However Willikie et al. teaches transferring said first packet to a 
host computer (see col. 3, lines 60-65, the QMIP unit creates a frame 
which carries data information and flow control information and forwards 
the frame over the common data link to a host computer( entity) ). 

Therefore it would have been obvious to one with ordinary skill in 
the art at the time the invention was made to combine Kerr et al. invention 
with Willikie et al. invention because Willikie et al. transfers data between 
multiple entities over a serial link in a efficient manner( see Willikie et al. 
see col. 3, lines 38-41). 

Applicants respectfully disagree with this rejection. As noted above, applicants 
respectfully disagree that "Kerr et al. discloses . . .decoding, by said network interface, a 
header of the first packet to determine a length of data to be stored in said destination 
entity, wherein said header conforms to a protocol above TCP( see col. 3, lines 25-34, a 
message flow may be identified responsive to other factors. These other factors may 
include one or more of the following: information in packet headers the packet length)." 
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The citation of Kerr that the Final Rejection relies upon as allegedly disclosing this claim 
recitation reads: 

For example, in alternative embodiments, a message flow may be 
bi-directional instead of unidirectional, a message flow may be identified 
at a different protocol layer level than that of transport service access 
points, or a message flow may be identified responsive to other factors. 
These other factors may include one or more of the following: information 
in packet headers, packet length, time of packet transmission, or routing 
conditions on the network (such as relative network congestion or 
administrative policies with regard to routing and transmission). 

There is simply nothing in this quotation, or in the remainder of Kerr, that teaches 
"decoding, by said network interface, a header. . . wherein said header conforms to a 
protocol above TCP." There is no "protocol above TCP" mentioned. Packet length 
would have been easy for the router of Kerr to determine without decoding any header, 
by simply counting the bytes of the packet. Further, decoding a header of a layer above 
TCP would have been useless and a waste of processing resources for the router of Kerr, 
which operated at layers below TCP. For at least these reasons, the Final Rejection has 
not presented a prima facie case of obviousness for claims 3 or 22. 

Applicants also respectfully note that the Final Rejection does not address the 
recitation in claim 3 of "transferring said header of said first packet to said host computer 
for processing said data" or the recitation in claim 22 of "transferring said header of said 
first packet to said host computer for data associated with said first packet." These 
recitations relate to earlier respective recitations that "said header conforms to a protocol 
above TCP." As noted above, however, there is no "protocol above TCP" mentioned that 
the header conforms to and that is decoded by the network interface. For at least these 
additional reasons, the Final Rejection has not presented a prima facie case of 
obviousness for claims 3 or 22. 

Moreover, applicants respectfully disagree that "it would have been obvious to 
one with ordinary skill in the art at the time the invention was made to combine Kerr et 
al. invention with Willkie et al. invention because Willkie et al. transfers data between 
multiple entities over a serial link in a efficient manner( see Willkie et al. see col. 3, lines 
38-41)." Instead, col. 3, lines 38-41 of Willkie state: 
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Therefore, there is a need in the art for a means of transferring data 
between multiple entities over a single serial link. The invention fulfills 
this need in an efficient manner. 

In other words, Willkie stresses the importance of "a single serial link." In 
contrast, Kerr is directed to "a technique for network switching and data export 
responsive to message flow patterns." Col. 1, lines 43-45. Because Willkie and Kerr are 
directed to contradictory purposes, a person of ordinary skill in the art would not have 
combined Kerr and Willkie as proposed by the Final Rejection. For at least this 
additional reason, the Final Rejection has not presented a prima facie case of obviousness 
for claims 3 and 22. 

Because of the multiple reasons why the Final Rejection has not presented a 
prima facie case of obviousness for claims 3 and 22, applicants respectfully assert that 
claims 3 and 22 and all the claims that depend from claims 3 and 22 are nonobvious, and 
respectfully request that the rejection of those claims be withdrawn. 



C. Claims 2 and 24 

Regarding claims 2 and 24, the Office Action states: 

Regarding Claims 2 and 24 Kerr et al. discloses everything as 
applied above (see claims 1 and 3). 

prior to said storing a first flow identifier, parsing said first packet 
to retrieve said identifier of the source entity and said identifier of the 
destination entity( see col. 3, lines 56-67, the routing device examines a 
header for the packet, to retrieve identifiers). 

Claim 2 depends from claim 1 and claim 24 depends from claim 3, which are 
nonobvious over Kerr in view of Willkie, as discussed above, and so claims 2 and 24 are 
also nonobvious. 



D. Claim 4 

Regarding claim 4, the Office Action states: 

Regarding Claim 4 Kerr et al. discloses everything as applied 
above (see claim 3). 

transferring said second packet to said host computer( see col. 3, 
lines 55-56, the router receive packet, by definition the router receives 
packet than forwards the packet to destination); 
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wherein said host computer is configured to collectively process a 
data portion of said first packet and a data portion of said second packet in 
accordance with said protocol (see col. 2-3, lines 50-2, the router, 
processes in accordance to a transmission protocol type of the first packet, 
see col. 3, lines 57-67, the header is examined, the destination device (host 
computer) will process the packet likewise). 

Claim 4 depends from claim 3, which recites in part "a protocol above TCP," so 
that the recitation in claim 4 of "said protocol" refers to "a protocol above TCP." 
Applicants respectively assert that neither the "transmission protocol" mentioned in "col. 
2-3, lines 50-2" nor "the header is examined" mentioned in "col. 3, lines 57-67" disclose 
processing in accordance with a protocol above TCP. 

For at least this additional reason, the Final Rejection has not presented a prima 
facie case of obviousness for claim 4. 



E. Claims 5 and 18 

Regarding claims 5 and 18, the Office Action states: 

Regarding Claims 5 and 18 Kerr et al. discloses everything as 
applied above (see claims 3 and 16). 

wherein said identifying comprises: 

receiving, by said network interface a flow key generated by 
concatenating an identifier of the source entity and an identifier of the 
destination entity( see col. 6, lines 32-41, the flow keys , with information 
about message flows to include the source and the destination flow 
identifiers); 

wherein said first flow identifier comprises said flow key( see col. 
6, lines 32-41, the flow cache includes the flow keys about the messages 
flows). 

Claim 5 depends from claim 3, which is nonobvious over Kerr in view of Willkie, 
as discussed above, and so claim 5 is also nonobvious. Claim 16 was not actually 
rejected above, but as discussed below, claim 16 is nonobvious over Kerr in view of U.S. 
Patent No. 5,819,1 1 1 to Davies et al. ("Davies"). Claim 18 depends from claim 16 and 
so is also nonobvious. 

Moreover, applicants respectfully disagree that Kerr teaches "receiving, by said 
network interface a flow key. . . " Col. 6, lines 32-41 does disclose "flow keys 3 1 0," but 
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does not teach that the flow keys are received by the router that the Final Rejection 
asserts is a network interface. 

For at least these additional reasons, the Final Rejection has not presented a prima 
facie case of obviousness for claims 5 and 18. 



F. Claims 6 and 17 

Regarding claims 6 and 17, the Office Action states: 

Regarding Claims 6 and 17 Kerr et al. discloses everything as 
applied above (see claims 3 and 16). 

wherein said identifying comprises: 

receiving, by said network interface an index of said first 
communication flow in a flow database; wherein said first flow identifier 
comprises said index( seel col. 6, lines 31-49, the flow cache had a 
buckets of entries, of a database flow, which comprises a four-byte 
pointer( reads on index)). 

Claim 6 depends from claim 3, which is nonobvious over Kerr in view of Willkie, 
as discussed above, and so claim 6 is also nonobvious. Claim 16 was not actually 
rejected above, but as discussed below, claim 16 has been amended and is nonobvious 
over Kerr in view of Davies. Claim 17 depends from claim 16 and so is also nonobvious. 

Moreover, applicants respectfully disagree that Kerr teaches "receiving, by said 
network interface an index of said first communication flow ..." Col. 6, lines 3 1-49 does 
disclose "buckets 301," but does not teach that the buckets are received by the router that 
the Final Rejection asserts is a network interface. 

For at least these additional reasons, the Final Rejection has not presented a prima 
facie case of obviousness for claims 6 and 17. 



G. Claim 7 

Regarding claim 7, the Office Action states: 

Regarding Claim 7 Kerr et al. discloses everything as applied 
above (see claim 3). 

wherein said determining comprises comparing said first flow 
identifier with a second flow identifier associated with a second packet 
received at said communication device (see col. 4, lines 1-7, the routing 
device performs lookup in a flow cache comparing the flow identifiers 
with second packet to determine message flows). 
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Claim 7 depends from claim 3, which is nonobvious over Ken- in view of Willkie, 
discussed above, and so claim 7 is also nonobvious. 



H. Claim 8 

Regarding claim 8, the Office Action states: 

Regarding Claim 8 Kerr et al. discloses everything as applied 
above (see claim 7). 

wherein said determining further comprises: 

storing said first flow identifier in a flow memory ( see col. 6, lines 
29-50, the flow cache stores the flow identifiers in a flow memory) ; and 

storing said second flow identifier in said flow memory( see col. 6, 
lines 29-50, the second flow identifier is stored); and 

comparing said stored first flow identifier and said stored second 
flow identified see col. 4, lines 1-7, the message flow is identified by 
comparing flow identifiers). 

Claim 8 depends from claim 7, which is nonobvious over Kerr in view of Willkie, 
discussed above, and so claim 8 is also nonobvious. 

I. Claim 9 

Regarding claim 9, the Office Action states: 

Regarding Claim 9 Kerr et al. discloses everything as applied 
above (see claim 8). 

wherein said flow memory is an associative memory in said 
communication device (see figure 3, section 300 flow caches). 

Claim 9 depends from claim 8, which is nonobvious over Kerr in view of Willkie, 
discussed above, and so claim 9 is also nonobvious. 

J. Claim 10 

Regarding claim 10, the Office Action states: 

Regarding Claim 10 Kerr et al. discloses everything as applied 
above (see claim 3). 

storing said first packet in a packet memory (see col. 7, lines 59- 
61, collecting information about message flow patterns, to include, see col. 
8, lines 4-16, collecting ( storing) actual data, packets transmitted as part 
of the flow itself) see col. 2, lines 40-45, the router stores the packet in its 
memory). 
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Claim 10 depends from claim 3, which is nonobvious over Kerr in view of 
Willkie, as discussed above, and so claim 10 is also nonobvious. 



K. Claim 1 1 

Regarding claim 1 1, the Office Action states: 

Regarding Claim 11 Kerr et al. discloses everything as applied 
above (see claim 10). 

wherein said determining comprises comparing said first flow 
identifier configured to identify said first communication flow with a 
second flow identifier configured to identify a second communication 
flow comprising a packet stored in said packet memory (see col. 4, lines 1- 
7, the message flow is identified by comparing flow identifiers, if new 
flow is determined or old message flow). 

Claim 1 1 depends from claim 10, which is nonobvious over Kerr in view of 
Willkie, as discussed above, and so claim 1 1 is also nonobvious. 



L. Claim 19 

Regarding claim 1 9, the Office Action states: 

Regarding Claim 19 Kerr et al. discloses everything as applied 
above (see claim 16). 

wherein said packet memory comprises said flow memory (see col. 
3, lines 40-48, the routing device (packet memory, maintains the flow 
cache)). 

Claim 1 1 depends from claim 10, which is nonobvious over Kerr in view of 
Willkie, as discussed above, and so claim 1 1 is also nonobvious. 

Moreover, applicants respectfully disagree that Ken- teaches "wherein said packet 
memory comprises said flow memory." Col. 3, lines 40-48 does disclose a "flow cache," 
but does not teach that the packet memory includes the flow cache. 

For at least this additional reason, the Final Rejection has not presented a prima 
facie case of obviousness for claim 19. 



M. Claims 20 and 27 

Regarding claims 20 and 27, the Office Action states: 
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Regarding Claims 20 and 27 Kerr et al. discloses everything as 
applied above (see claims 16 and 3). 

storing a first indicator in a host memory if said communication 
flow comprises said second packet; and storing a second indicator in said 
host memory if said first packet is the only packet in said packet memory 
that is part of said communication flow (see col. 4, lines 1-7, the message 
flow is identified by comparing flow identifiers, if new flow is determined 
or old message flow). 

Claim 16 was not actually rejected above, but as discussed below, claim 16 is 
nonobvious over Kerr in view of Davies. Claim 20 depends from claim 16 and so is also 
nonobvious. Claim 27 depends from claim 3, which is nonobvious over Kerr in view of 
Willkie, as discussed above, and so claim 27 is also nonobvious. 

Applicants also respectfully disagree that "Kerr et al. discloses . . . storing a 
second indicator in the destination entity if said first packet is the only packet stored in 
the packet memory that is part of said first communication flow( see col. 4, lines 1-7, the 
flow is identified as new if the first packet only packet part of the communication flow)." 
Although "col. 4, lines 1-7" of Kerr disclose determining whether "the identified message 
flow 160 is a 'new' message flow 160," Kerr does not teach that this determination is 
stored in the destination entity. Moreover, Kerr does not disclose that a second indicator 
is stored besides the first indicator, regardless of whether the packet is "new." 

For at least these additional reasons, the Final Rejection has not presented a prima 
facie case of obviousness for claims 20 and 27. 



N. Claims 21, 25 and 26 

Regarding claims 21, 25 and 26, the Office Action states: 

Regarding Claims 21, 25 and 26 Kerr et al. discloses a 
communication interface, comprising: 

a header parser configured to parse a header of a first packet 
received at the communication interface, wherein the first packet was 
issued from a source entity for a destination entity( see col. 3, lines 57-67, 
the router device examines the headers of the received packets, see figure 
1, communication interface attached via a communication link); 

a flow database configured to facilitate management of a 
communication flow comprising the first packet, the flow database 
comprising( seel col. 6, lines 31-49, the flow cache had a buckets of 
entries, of a database flow, which comprises a four-byte pointer( reads on 
index)): 
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a flow key configured to identify the communication flow using 
identifiers of the source entity and the destination entity( see col. 6, lines 
32-36, the flow cache, comprise a memory which associated flow keys 
which include the source and the destination); 

an activity indicator configured to indicate a recency with which a 
packet in the communication flow has been received( see col. 5, lines 51- 
54, at step 241, the routing device examines, in the flow cache and 
compares the current time with the last time a packet was routed using a 
particular entry); and 

a validity indicator for indicating whether the communication flow 
is valid( see col. 3, lines 39-49, the routing device maintains the flow 
cache and remove message flow that are no longer valid. Indicating 
message flow is no longer valid); 

a code generator configured to generate an operation code for the 
first packet, to facilitate forwarding of the first packet toward the 
destination entity( see col. 6, lines 29-41, the flow cache has flow keys 
that reads on operation code, which includes information about a 
particular message flow); and 

a packet batching module configured to determine whether a 
second packet received at the communication interface is part of the 
communication flow( see col. 3-4, lines 57-7, the router device identifies a 
message flow by comparing received packets ). 

said flow identifier including source and destination Transmission 
Control Protocol (TCP) port numbers (see col. 2 line 61- col. 3 line 2, a 
message flow 160 is defined by a network-layer address for a particular 
source device 120, a particular port number at the source device 120, a 
network-layer address for a particular destination device 130, a particular 
port number at the destination device 130, and a particular transmission 
protocol type. For example, the transmission protocol type may identify a 
lcnown transmission protocol, such as TCP); 

decoding, by said network interface, a header of the first packet to 
determine a length of data to be stored in said destination entity, wherein 
said header conforms to a protocol above TCP( see col. 3, lines 25-34, a 
message flow may be identified responsive to other factors. These other 
factors may include one or more of the following: information in packet 
headers the packet length); 

Applicants respectfully note that the Final Rejection fails to even allege that Kerr 
and Willkie disclose various recitations of claims 21, 25 and 26. 

For example, claim 21 recites in part "a network interface for a host computer, the 
network interface configured to receive a first packet from a network and transfer at least 
a data portion of said first packet to a host computer memory." The Final Rejection 
probably does not even allege that this recitation is disclosed by the cited art because the 
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router of Kerr, which the Final Rejection elsewhere terms a "network interface," does not 
transfer "a data portion of said first packet to a host computer memory." 

Other recitations of claim 21 that do not receive even a cursory rejection include: 

a packet memory configured to store said first packet; 

a flow memory for storing a first flow number associated with said 
first packet, wherein said first flow number is configured to identify a 
communication flow comprising said first packet; 

a packet batcher configured to determine whether the 
communication flow includes a second packet stored in said packet 
memory after said first packet; and a notifier configured to: 

store a first code in a host indicator if said packet memory includes 
the second packet; and 

store a second code in said host indicator if said packet memory 
does not include the second packet; and 

a processor for processing a header portion of said first packet and 
determining a length of data to be stored in the destination entity, wherein 
said header portion conforms to a protocol above Transmission Control 
Protocol (TCP). 

In short, the Final Rejection has not presented a prima facie case of obviousness 
for claim 21. 

Similarly, the Final Rejection fails to even allege that Ken- and Willkie disclose 
recitations of claim 25. For instance, claim 25 recites in part "a header parser configured 
to parse a header of a first packet received at the communication interface, the header 
including a Transmission Control Protocol (TCP) header and a header above TCP that is 
decoded to determine a length of data being received." The Final Rejection probably 
does not even allege that this recitation is disclosed by the cited art because Kerr and 
Willkie do not disclose "a header above TCP that is decoded to determine a length of data 
being received." As discussed above regarding claim 1, applicants respectfully disagree 
that "Kerr et al. discloses . . .decoding, by said network interface, a header of the first 
packet to determine a length of data to be stored in said destination entity, wherein said 
header conforms to a protocol above TCP( see col. 3, lines 25-34, a message flow may be 
identified responsive to other factors. These other factors may include one or more of the 
following: information in packet headers the packet length)." 

Thus, the Final Rejection has not presented a prima facie case of obviousness for 
claim 25. 
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Similarly, the Final Rejection fails to even allege that Kerr and Willkie disclose 
recitations of claim 26. For instance, claim 26 recites in part "assigning an operation 
code to the first packet, said operation code indicating whether a portion of data in the 
first packet is reassembleable with another portion of data in another packet in the 
communication flow." The Final Rejection probably does not even allege that this 
recitation is disclosed by the cited ait because Kerr and Willkie do not disclose such an 
operation code or its assignment. In addition, the Final Rejection does not allege that 
Kerr and Willkie disclose "decoding, by the communication interface, a second header 
portion of the first packet to determine a length of data being received, said second 
header portion conforming to a protocol above TCP." 

In short, the Final Rejection has not presented a prima facie case of obviousness 
for claim 26. 



III. 35 USC §103 - Kerr in view of Davies 

The Office Action rejects claims 14-16 and 23 under 35 USC § 103(a) as allegedly 
being unpatentable over Kerr in view of Davies. 

A. Claim 16 

Regarding claim 16, the Office Action states: 

Regarding Claim 16 Kerr et al. discloses a method of transferring 
a packet from a network interface to a host computer, comprising: 

receiving a first packet at a network interface( see col. 3, lines 55- 
56, receives a packet, see figure 1, section routing device); 

storing said first packet in a packet memory see col. 3, lines 55-67, 
the router stores packets) 

receiving a first flow identifier configured to identify a 
communication flow comprising said first packet(see col. 3, lines 57-67, 
flow identifying, identifying a flow for the packet, see col. 6, lines 29-41, 
the flow cache, stores the flow identifiers, including the source and the 
destination); 

storing said first flow identifier in a flow memory(see col. 6, lines 
29-41, the flow cache, stores the flow identifiers, including the source and 
the destination); 

searching said flow memory for a second packet in said 
communication flow received at the network interface after said first 
packet( see col. 3, lines 49-67, the router determines the message flow of 
the received packets); 
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transferring header of said first packet to said host computer(see 
col. 8, lines 35-59, the router builds an information packet which is then 
sent to a destination device (host computer), in accordance to a 
communication protocol, for processing, see col. 2-3, lines 50-2, the 
router, processes in accordance to a transmission protocol type of the first 
packet , see col. 3, lines 57-60, routing device examines the header); and 

including source and destination Transmission Control Protocol 
(TCP) port numbers (see col. 21ine 61- col. 31ine 2, a message flow 160 is 
defined by a network-layer address for a particular source device 120, a 
particular port number at the source device 120, a network-layer address 
for a particular destination device 130, a particular port number at the 
destination device 130, and a particular transmission protocol type. For 
example, the transmission protocol type may identify a known 
transmission protocol, such as TCP); 

decoding, by said network interface, a header of the first packet to 
determine a length of data to be stored in said destination entity, wherein 
said header conforms to a protocol above TCP( see col. 3, lines 25-34, a 
message flow may be identified responsive to other factors. These other 
factors may include one or more of the following: information in packet 
headers the packet length); 

Kerr et al. fails to specifically point out configuring an indicator in 
a host memory to indicate whether processing of said first packet by said 
host computer should be delayed to await transfer of said second packet to 
said host memory as claimed. 

Davies et al. teaches configuring an indicator in a host memory to 
indicate whether processing of said first packet by said host computer 
should be delayed to await transfer of said second packet to said host 
memory (See col 4, lines 8-13, The disabling step can include checking if 
a run length encoded data transfer is pending from the host, and if so, 
delaying disabling of the data transfers from the host to the peripheral until 
a data byte associated with the run length encoded data is received by the 
interface controller, otherwise do not delay). 

Therefore it would have been obvious to one with ordinary skill in 
the art at the time the invention was made to combine Kerr et al. invention 
with Davies et al. invention because Davies et al. invention provides 
provide methods and apparatus for reducing the complexity of 
programming on the peripheral side of an IEEE interface (see Davies et al. 
col. 3, lines 10-16) 

Applicants respectfully disagree with this rejection. As discussed above 
regarding claim 1, there is no teaching in Kerr of "decoding, by said network interface, a 
header of the first packet to determine a length of data to be stored in said destination 
entity, wherein said header conforms to a protocol above TCP." 
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Moreover, applicants respectfully note that the Final Rejection again fails to even 
allege that the cited art discloses certain claim recitations. For example, the Final 
Rejection fails to even allege that Davies teaches "configuring an indicator in a host 
memory to indicate whether processing of a remainder of said first packet by said host 
computer should be delayed to await transfer of said second packet to said host memory." 
For at least this reason, the Final Rejection has not presented a prima facie case of 
obviousness for claim 16. 

Further, applicants respectfully disagree that "Davies et al. teaches configuring an 
indicator in a host memory to indicate whether processing of said first packet by said host 
computer should be delayed to await transfer of said second packet to said host memory. 
(See col 4, lines 8-13, The disabling step can include checking if a run length encoded 
data transfer is pending from the host, and if so, delaying disabling of the data transfers 
from the host to the peripheral until a data byte associated with the run length encoded 
data is received by the interface controller, otherwise do not delay)." Note that claim 16 
recites in part "delayed to await transfer of said second packet to said host memory," 
whereas the delay of Davies quoted by the Final Rejection is instead "from the host to the 
peripheral." For at least this additional reason, the Final Rejection has not presented a 
prima facie case of obviousness for claim 16. 

In addition, applicants respectfully disagree that "it would have been obvious to 
one with ordinary skill in the art at the time the invention was made to combine Kerr et 
al. invention with Davies et al. invention because Davies et al. invention because Davies 
et al. invention provides provide methods and apparatus for reducing the complexity of 
programming on the peripheral side of an IEEE interface (see Davies et al. col. 3, lines 
10-16)" The peripheral side of the "IEEE 1284 interface" taught by Davies is a printer 
that is directly attached to a computer by a parallel bus. Col. 1, lines 15-67. This is a far 
cry from the network router taught by Kerr. 

Moreover, the "delay" taught by Davies and cited by the Final Rejection involves 
particular interactions between specific modes of the IEEE 1284 standard, the "host 
transfer recovery (HTR) cycle" and the "enhanced compatibility port (ECP) mode" that 
includes a "run length encoded (RLE) data compression." Col. 1, line 22 - col. 3, line 
13. There is no indication that the interaction between these parallel bus modes for the 
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direct attached printer of Davies would be at all useful or even possible for the network 
router of Kerr. Indeed, the only realistic result of combining Kerr with Davies as 
proposed by the Final Rejection, if such combination would even be possible without 
destroying Kerr, is an unnecessary increase in the complexity of Kerr, quite the opposite 
of the incentive proposed by the Final Rejection. 

For at least these additional reasons, the Final Rejection has not presented a prima 
facie case of obviousness for claim 16. 

Because of the multiple reasons why the Final Rejection has not presented a 
prima facie case of obviousness for claim 16, applicants respectfully assert that claim 16 
and all the claims that depend from claim 16 are nonobvious, and respectfully request 
that the rejection of those claims be withdrawn. 



B. Claim 23 

Regarding Claim 23 Kerr et al. discloses a processor readable 
storage medium containing a data structure configured to store 
information concerning a packet to be transferred from a network interface 
to a host computer, the data structure including one or more entries, each 
entry comprising: 

a flow number configured to identify a communication flow 
comprising a first packet received at the network interface from a source 
entity for a destination entity associated with the host computer( see col. 6, 
lines 29-41, the flow cache has flow keys that reads on flow number); and 

a validity indicator configured to provide( see col. 3, lines 39-49, 
the routing device maintains the flow cache and remove message flow that 
are no longer valid. Indicating message flow is no longer valid); 

wherein said data structure is searched for a second entry 
containing said flow number when said first packet is transferred to the 
host computer to determine if said communication flow also comprises a 
second packet received at the network interface after said first packet (see 
col. 3-4, lines 57-7, the routing device identifies a message flow, the 
packets are compared to determine if is part of a message flow). 

including source and destination Transmission Control Protocol 
(TCP) port numbers (see col. 21ine 61- col. 31ine 2, a message flow 160 is 
defined by a network-layer address for a particular source device 120, a 
particular port number at the source device 120, a network-layer address 
for a particular destination device 130, a particular port number at the 
destination device 130, and a particular transmission protocol type. For 
example, the transmission protocol type may identify a known 
transmission protocol, such as TCP); 
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Kerr et al. fails to specifically point out a first indication if said 
first packet is ready for transfer to the host computer; and a second 
indication if said first packet is a control packet as claimed; 

Davies et al teaches a first indication if said first packet is ready for 
transfer to the host computer (See col 4, lines 1-13, The disabling step can 
include checking if a run length encoded data transfer is pending from the 
host, and if so, delaying disabling of the data transfers from the host to the 
peripheral until a data byte associated with the run length encoded data is 
received by the interface controller, otherwise do not delay, the disabling 
step reads on an indication, and control status flag indicates that the data 
is ready, error free and pending) 

a second indication if said first packet is a control packet( see col. 
3, lines 28-41, method can include after execution of the step of 
transferring a data block, either setting the interface controller to disable 
acknowledgment of receipt of data if a flow control status flag indicates 
pending flow stop, receiving of control packets) 

Therefore it would have been obvious to one with ordinary skill in 
the art at the time the invention was made to combine Kerr et al. invention 
with Davies et al. invention because Davies et al. invention provides 
provide methods and apparatus for reducing the complexity of 
programming on the peripheral side of an IEEE interface (see Davies et al. 
col. 3, lines 10-16). 

Applicants respectfully disagree with this rejection. The Final Rejection of claim 
23 fails to even assert that the cited art discloses "a header conforming to a protocol 
above TCP, the header decoded by the network interface." As discussed above 
regarding claim 1, however, there is no such teaching in Kerr. 

Further, applicants respectfully disagree that "Davies et al. teaches ... a second 
indication if said first packet is a control packet( see col. 3, lines 28-41, method can 
include after execution of the step of transferring a data block, either setting the interface 
controller to disable acknowledgment of receipt of data if a flow control status flag 
indicates pending flow stop, receiving of control packets)." Instead, "col. 3, lines 28-41" 
of Davies state: 

Embodiments of the invention include the following features. The 
method can include after execution of the step of transferring a data block, 
either setting the interface controller to disable acknowledgment of receipt 
of data if a flow control status flag indicates pending flow stop; or if not, 
setting the flow control status flag to indicate pending flow stop if the 
large capacity buffer has insufficient space to hold one data block from the 
plurality of small capacity buffers. 
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The disabling of acknowledgment of receipt of data can be delayed 
if a run length encoded data transfer is pending until an RLE data byte 
associated with the end of the pending run length encoded data transfer is 
received by the interface controller. 

Although this passage mentions "a flow control status flag," it does not teach or 
suggest a ". . . a second indication if said first packet is a control packet." For at least this 
additional reason, the Final Rejection has not presented a prima facie case of obviousness 
for claim 23. 

In addition, applicants respectfully disagree that "it would have been obvious to 
one with ordinary skill in the art at the time the invention was made to combine Kerr et 
al. invention with Davies et al. invention because Davies et al. invention because Davies 
et al. invention provides provide methods and apparatus for reducing the complexity of 
programming on the peripheral side of an IEEE interface (see Davies et al. col. 3, lines 
10-16)" The peripheral side of the "IEEE 1284 interface" taught by Davies is a printer 
that is directly attached to a computer by a parallel bus. Col. 1, lines 15-67. This is a far 
cry from the network router taught by Kerr. 

Moreover, the "delay" taught by Davies and cited by the Final Rejection involves 
particular interactions between specific modes of the IEEE 1284 standard, the "host 
transfer recovery (HTR) cycle" and the "enhanced compatibility port (ECP) mode" that 
includes a "run length encoded (RLE) data compression." Col. 1, line 22 - col. 3, line 
13. There is no indication that the interaction between these parallel bus modes for the 
direct attached printer of Davies would be at all useful or even possible for the network 
router of Kerr. Indeed, the only realistic result of combining Kerr with Davies as 
proposed by the Final Rejection, if such combination would even be possible without 
destroying Kerr, is an unnecessary increase in the complexity of Kerr, quite the opposite 
of the incentive proposed by the Final Rejection. 

For at least these additional reasons, the Final Rejection has not presented a prima 
facie case of obviousness for claim 23, and applicants respectfully request that the 
rejection of claim 23 be withdrawn. 



Request for Reconsideration 
Application Serial No: 10/678,336 



30 



IV. Conclusion 

For the many reasons mentioned above, applicants respectfully assert that the 
Final Rejection has not presented a prima facie case of obviousness for a single claim. 
Applicants respectfully submit that the pending claims are in condition for allowance, 
and a Notice of Allowance is solicited. 



Respectfully submitted, 

/Mark Lauer/ 
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